قمت مؤخرًا بتشغيل بعض أكواد JavaScript الخاصة بي من خلال Crockford's JSLint ، وأعطيت الخطأ التالي: مشكلة في السطر 1 الحرف 1: عبارة "use strict" مفقودة. بعد إجراء بعض البحث ، أدركت أن بعض الأشخاص يضيفون "استخدام صارم" ؛ في كود JavaScript الخاص بهم. بمجرد إضافة العبارة ، توقف الخطأ عن الظهور. لسوء الحظ ، لم تكشف Google عن الكثير من التاريخ وراء بيان السلسلة هذا. بالتأكيد يجب أن يكون له علاقة بكيفية تفسير المتصفح لجافا سكريبت ، لكن ليس لدي أي فكرة عن تأثير ذلك. إذن ما هو "استخدام صارم" ؛ كل شيء ، ما الذي يعنيه ، وهل ما زال مناسبًا؟ هل يستجيب أي من المتصفحات الحالية لعبارة "use strict" ؛ سلسلة أم أنها للاستخدام في المستقبل؟
2020-12-07 22:03:55
قد تهمك هذه المقالة حول وضع Javascript Strict Mode: John Resig - ECMAScript 5 Strict Mode و JSON والمزيد لاقتباس بعض الأجزاء المثيرة للاهتمام: وضع Strict Mode هو ميزة جديدة في ECMAScript 5 تسمح لك بوضع برنامج أو وظيفة في سياق تشغيل "صارم". يمنع هذا السياق الصارم اتخاذ إجراءات معينة ويفرض المزيد من الاستثناءات. و: يساعد الوضع المتشدد بطريقتين: تلتقط بعض الأخطاء الغامضة الشائعة في الترميز ، مع استثناءات. يمنع الأخطاء أو يلقي بها عند اتخاذ إجراءات "غير آمنة" نسبيًا (مثل الوصول إلى الكائن العام). إنه يعطل الميزات المربكة أو التي لم يتم التفكير فيها بشكل جيد. لاحظ أيضًا أنه يمكنك تطبيق "الوضع المقيد" على الملف بأكمله ... أو يمكنك استخدامه فقط لوظيفة معينة (لا يزال مقتبسًا من مقالة جون ريسيج): // رمز غير صارم ... (وظيفة(){ "استخدام صارم" ؛ // حدد مكتبتك بدقة ... }) () ؛ // رمز غير صارم ... والذي قد يكون مفيدًا إذا كان عليك خلط الكود القديم والجديد ؛-) لذا ، أفترض أنه يشبه إلى حد ما "استخدام صارم" الذي يمكنك استخدامه في لغة Perl (ومن هنا جاء الاسم؟): فهو يساعدك على ارتكاب أخطاء أقل ، من خلال اكتشاف المزيد من الأشياء التي قد تؤدي إلى حدوث أعطال. الوضع الصارم مدعوم الآن من قبل جميع المتصفحات الرئيسية. داخل وحدات ECMAScript الأصلية (مع عبارات الاستيراد والتصدير) وفئات ES6 ، يتم تمكين الوضع المقيد دائمًا ولا يمكن تعطيله. | إنها ميزة جديدة في ECMAScript 5. كتب John Resig ملخصًا رائعًا لها. إنها مجرد سلسلة تضعها في ملفات جافا سكريبت (إما في الجزء العلوي من الملف أو داخل وظيفة) تبدو كما يلي: "استخدام صارم" ؛ لا ينبغي أن يتسبب وضعه في الكود الخاص بك الآن في أي مشاكل مع المتصفحات الحالية لأنه مجرد سلسلة. قد يتسبب ذلك في حدوث مشاكل مع التعليمات البرمجية الخاصة بك في المستقبل إذا كانت التعليمات البرمجية الخاصة بك تنتهك pragma. على سبيل المثال ، إذا كان لديك حاليًا foo = "bar" بدون تحديد foo أولاً ، فسيبدأ الرمز الخاص بك في الفشل ... وهذا أمر جيد في رأيي. | عبارة "استخدام صارمة" ؛ يوجه المتصفح لاستخدام الوضع المتشدد ، وهو عبارة عن مجموعة ميزات أقل أمانًا لجافا سكريبت. قائمة الميزات (غير شاملة) لا يسمح بالمتغيرات العامة. (يلتقط إعلانات var المفقودة والأخطاء المطبعية في أسماء المتغيرات) ستؤدي التعيينات الفاشلة الصامتة إلى حدوث خطأ في الوضع المقيد (تعيين NaN = 5 ؛) ستؤدي محاولات حذف الخصائص غير القابلة للحذف إلى طرح (حذف Object.prototype) يتطلب أن تكون جميع أسماء الخصائص في كائن حرفية فريدة (var x = {x1: "1"، x1: "2"}) يجب أن تكون أسماء معلمات الوظائف فريدة (مجموع الوظائف (س ، س) {...}) يحظر بناء الجملة الثماني (var x = 023 ؛ يفترض بعض المطورين خطأً أن الصفر السابق لا يغير الرقم.) يحظر مع الكلمة الأساسية لا تقدم Eval في الوضع المتشدد متغيرات جديدة يحظر حذف الأسماء العادية (حذف x ؛) يحظر ربط أو التنازل عن أسماء التقييم والحجج بأي شكل من الأشكال لا يقوم الوضع الصارم بتسمية خصائص كائن الوسائط باستخدام المعلمات الرسمية. (على سبيل المثال في الدالة sum (a، b) {وسيطات الإرجاع [0] + b؛} يعمل هذا لأن الوسيطات [0] مرتبطة بـ a وهكذا) arguments.callee غير مدعومة [المرجع: الوضع الصارم ، شبكة مطوري موزيلا] | إذا كان الناس قلقين بشأن الاستخدام الصارم ، فقد يكون من المفيد الاطلاع على هذه المقالة: ECMAScript 5 دعم "الوضع الصارم" في المتصفحات. ماذا يعني هذا؟ NovoGeek.com - مدونة كريشنا يتحدث عن دعم المتصفح ، ولكن الأهم من ذلك كيفية التعامل معه بأمان: الوظيفة هيStrictMode () { العودة! } / * إرجاع خطأ ، لأن "هذا" يشير إلى الكائن العالمي و "! هذا" يصبح خطأ * / الوظيفة هيStrictMode () { "استخدام صارم" ؛ العودة! } / * يعود صحيحًا ، لأنه في الوضع المتشدد الكلمة الرئيسية "هذا" لا يشير إلى كائن عالمي ، على عكس JS التقليدية. لذا هنا ، "هذا" "غير محدد" و "! هذا" يصبح صحيحًا. * / | كلمة تحذير ، جميع المبرمجين الذين يتقاضون صعوبة في الشحن: تطبيق "استخدام صارم" على الكود الحالي يمكن أن يكون خطيرًا! هذا الشيء ليس ملصقًا يشعرك بالرضا عن الوجه السعيد يمكنك لصقه على الكود لجعله "أفضل". مع "استخدام صارم" pragma ، سيقوم المتصفح فجأة بإلقاء استثناءات في أماكن عشوائية لم يرميها من قبل لمجرد أنك تقوم بشيء تسمح به JavaScript الافتراضي / الفضفاض بسعادة ولكن جافا سكريبت صارمة تمقت! قد يكون لديك انتهاكات صارمة مختبئة في مكالمات نادرًا ما تستخدم في التعليمات البرمجية الخاصة بك والتي لن تؤدي إلا إلى استثناء عندما يتم تشغيلها في النهاية - على سبيل المثال ، في بيئة الإنتاج التي يستخدمها العملاء الذين يدفعون لك! إذا كنت ستأخذ في الاعتبار ، فمن الجيد تطبيق "استخدام صارم" جنبًا إلى جنب مع اختبارات الوحدة الشاملة ومهمة إنشاء JSHint المهيأة بدقة والتي ستمنحك بعض الثقة في عدم وجود زاوية مظلمة من الوحدة الخاصة بك والتي ستنفجر بشكل مروع لمجرد أنك قمت بتشغيل الوضع الصارم. أو ، هناك خيار آخر: فقط لا تضف "استخدام صارم" إلى أي من التعليمات البرمجية القديمة ، فمن المحتمل أن تكون بهذه الطريقة أكثر أمانًا ، بصراحة. وبالتأكيد لا تضيف "استخدام صارم" إلى أية وحدات لا تمتلكها أو لا تمتلكهاصيانة ، مثل وحدات الطرف الثالث. أعتقد أنه على الرغم من كونه حيوانًا مميتًا في قفص ، إلا أن "استخدام صارم" يمكن أن يكون شيئًا جيدًا ، ولكن عليك القيام بذلك بشكل صحيح. أفضل وقت للتشدد هو عندما يكون مشروعك جديدًا وتبدأ من الصفر. قم بتكوين JSHint / JSLint مع جميع التحذيرات والخيارات التي تم ضبطها بأقصى قدر ممكن لفريقك ، واحصل على نظام بناء / اختبار / تأكيد جيد مثل Grunt + Karma + Chai ، وبعد ذلك فقط ابدأ في تعليم جميع وحداتك الجديدة على أنها " استخدام صارم ". كن مستعدًا لعلاج الكثير من الأخطاء والتحذيرات البسيطة. تأكد من أن الجميع يفهم الجاذبية من خلال تكوين البنية إلى FAIL إذا كان JSHint / JSLint ينتج أي انتهاكات. لم يكن مشروعي مشروعًا جديدًا عندما اعتمدت "استخدام صارم". نتيجة لذلك ، فإن IDE الخاص بي مليء بالعلامات الحمراء لأنني لا أمتلك "استخدام صارم" في نصف الوحدات الخاصة بي ، ويشكو JSHint من ذلك. إنه تذكير لي بما يجب أن أفعله لإعادة البناء في المستقبل. هدفي هو أن أكون خاليًا من العلامات الحمراء بسبب كل عبارات "الاستخدام الصارم" المفقودة ، ولكن هذه سنوات بعيدة الآن. | استخدام "استخدام صارم" ؛ لا يجعل شفرتك أفضل فجأة. وضع JavaScript Strict هو ميزة في ECMAScript 5. يمكنك تمكين الوضع المتشدد بإعلان ذلك في الجزء العلوي من البرنامج النصي / الوظيفة. "استخدام صارم" ؛ عندما يرى محرك JavaScript هذا التوجيه ، سيبدأ في تفسير التعليمات البرمجية في وضع خاص. في هذا الوضع ، تظهر الأخطاء عند اكتشاف ممارسات ترميز معينة يمكن أن ينتهي بها الأمر إلى أخطاء محتملة (وهذا هو السبب وراء الوضع المتشدد). ضع في اعتبارك هذا المثال: فار أ = 365 ؛ فار ب = 030 ؛ في هوسهم بمحاذاة القيم الرقمية ، قام المطور عن غير قصد بتهيئة المتغير b بحرف ثماني. سوف يفسر الوضع غير المقيد هذا على أنه حرفي رقمي بالقيمة 24 (في الأساس 10). ومع ذلك ، سيؤدي الوضع المتشدد إلى ظهور خطأ. للحصول على قائمة غير شاملة للتخصصات في الوضع المتشدد ، راجع هذه الإجابة. أين يجب أن أستخدم "use strict" ؛؟ في تطبيق JavaScript الجديد الخاص بي: بالتأكيد! يمكن استخدام الوضع الصارم كمبلغ عن المخالفات عندما تفعل شيئًا غبيًا باستخدام التعليمات البرمجية الخاصة بك. في كود JavaScript الموجود لدي: ربما لا! إذا كانت شفرة JavaScript الموجودة لديك تحتوي على عبارات محظورة في الوضع المتشدد ، فسيتوقف التطبيق ببساطة. إذا كنت تريد الوضع المتشدد ، فيجب أن تكون مستعدًا لتصحيح الأخطاء البرمجية الموجودة لديك وتصحيحها. هذا هو السبب في استخدام "استخدام صارمة" ؛ لا تجعل شفرتك أفضل فجأة. كيف أستخدم الوضع المتشدد؟ أدخل "استخدام صارم" ؛ بيان أعلى البرنامج النصي الخاص بك: // الملف: myscript.js "استخدام صارم" ؛ فار أ = 2 ؛ .... لاحظ أنه سيتم تفسير كل شيء في الملف myscript.js في الوضع المتشدد. أو أدخل "استخدام صارم" ؛ بيان أعلى جسم وظيفتك: وظيفة doSomething () { "استخدام صارم" ؛ ... } كل شيء في النطاق المعجمي للوظيفة سيتم تفسير شيء ما في الوضع الصارم. النطاق المعجمي للكلمة مهم هنا. على سبيل المثال ، إذا كانت التعليمات البرمجية الصارمة الخاصة بك تستدعي وظيفة مكتبة غير صارمة ، يتم تنفيذ التعليمات البرمجية الخاصة بك فقط في الوضع المتشدد ، وليس الوظيفة التي يتم استدعاؤها. انظر إلى هذه الإجابة للحصول على شرح أفضل. ما الأشياء المحظورة في الوضع الصارم؟ لقد وجدت مقالًا لطيفًا يصف عدة أشياء محظورة في الوضع المتشدد (لاحظ أن هذه ليست قائمة حصرية): نطاق تاريخيا ، تم الخلط بين JavaScript حول كيفية الوظائف يتم تحديد نطاقها. في بعض الأحيان يبدو أنها محددة النطاق بشكل ثابت ، لكن بعضها الميزات تجعلهم يتصرفون كما لو تم تحديد نطاقهم ديناميكيًا. هذا هو محيرة ، مما يجعل من الصعب قراءة البرامج وفهمها. سوء الفهم يسبب الخلل. إنها أيضًا مشكلة في الأداء. سيسمح تحديد النطاق الثابت بحدوث ارتباط متغير عند التجميع الوقت ، ولكن شرط النطاق الديناميكي يعني أن الالتزام يجب أن يكون إلى وقت التشغيل ، والذي يأتي بأداء مميز ضربة جزاء. يتطلب الوضع الصارم أن يتم تنفيذ جميع عمليات الربط المتغيرة بشكل ثابت. هذا يعني أن الميزات التي كانت تتطلب سابقًا ربطًا ديناميكيًا يجب حذفها أو تعديلها. على وجه التحديد ، العبارة with هي تم التخلص منها ، وقدرة وظيفة التقييم على التلاعب بـ بيئة المتصل بها مقيدة بشدة. إحدى مزايا التعليمات البرمجية الصارمة هي أن أدوات مثل YUI Compressor يمكنه القيام بعمل أفضل عند معالجته. المتغيرات العالمية الضمنية تضمنت JavaScript متغيرات عامة. إذا أنت لا تعلن صراحة عن متغير ، المتغير العام هو أعلن ضمنيًا لك. هذا يجعل البرمجة أسهل لـ المبتدئين لأنهم يستطيعون إهمال بعض التدبير المنزلي الأساسي الأعمال المنزلية. لكنه يجعل إدارة البرامج الأكبر أكثر من ذلك بكثير صعب ويقلل بشكل كبير من الموثوقية. لذلك بدقة الوضع ، لم يعد يتم إنشاء المتغيرات العامة الضمنية. يجب أعلن صراحة عن جميع المتغيرات الخاصة بك. التسرب العالمي هناك عدد من المواقف التي يمكن أن تسبب ذلك ليكون مرتبطًا بالكائن العالمي. على سبيل المثال ، إذا نسيت توفير البادئة الجديدة عند استدعاء المُنشئوظيفة منشئ هذا سيكون مرتبطًا بشكل غير متوقع بالكائن العام ، لذلك بدلاً من تهيئة كائن جديد ، سيكون بصمت بدلاً من ذلك العبث بالمتغيرات العالمية. في هذه الحالات ، سوف يكون الوضع المتشدد بدلاً من ذلك ، قم بربط هذا بـ undefined ، مما سيؤدي إلى قيام المنشئ بـ طرح استثناء بدلاً من ذلك ، مما يسمح باكتشاف الخطأ كثيرًا عاجلا. فشل صاخب لطالما احتوت JavaScript على خصائص للقراءة فقط ، لكنك لم تتمكن من إنشائها بنفسك حتى Object.createProperty لـ ES5 كشفت وظيفة تلك القدرة. إذا حاولت تعيين قيمة إلى خاصية للقراءة فقط ، فإنها ستفشل بصمت. سوف الاحالة لا يغير قيمة الخاصية ، ولكن برنامجك سيستمر على هذا النحو على الرغم من أنه كان. هذا خطر على السلامة يمكن أن يتسبب في البرامج الدخول في حالة غير متناسقة. في الوضع المتشدد ، تحاول تغيير ملف ستطرح خاصية القراءة فقط استثناءً. أوكتال كان التمثيل الثماني (أو الأساس 8) للأرقام للغاية مفيد عند القيام ببرمجة على مستوى الآلة على الأجهزة التي تتحدث كانت الأحجام من مضاعفات 3. كنت بحاجة إلى ثماني عند العمل مع CDC 6600 حاسوب مركزي ، بحجم كلمة 60 بت. إذا كنت تستطيع القراءة ثماني ، يمكنك النظر إلى كلمة على هيئة 20 رقمًا. يتم تمثيل رقمين رمز المرجع ، ورقم واحد حدد واحدًا من 8 سجلات. أثناء ال كان الانتقال البطيء من رموز الآلة إلى اللغات عالية المستوى يعتقد أنه مفيد في توفير أشكال ثماني في لغات البرمجة. في C ، كان تمثيل مؤسف للغاية للثمانية المحدد: صفر بادئ. لذا في C ، 0100 تعني 64 ، وليس 100 ، و 08 هي خطأ ، ليس 8. ولسوء الحظ ، كانت هذه المفارقة التاريخية نسخ إلى جميع اللغات الحديثة تقريبًا ، بما في ذلك JavaScript ، حيث يتم استخدامه فقط لإنشاء أخطاء. ليس لها أي غرض آخر. حتى في الوضع المتشدد ، لم يعد مسموحًا بالأشكال الثمانية. إلى آخره تصبح مصفوفة الوسائط الزائفة أكثر قليلاً مجموعة تشبه في ES5. في الوضع الصارم ، يفقد المستدعي والمتصل الخصائص. هذا يجعل من الممكن تمرير حججك إلى غير موثوق بها رمز دون التخلي عن الكثير من السياق السري. أيضا ، يتم استبعاد خاصية الحجج للوظائف. في الوضع المتشدد ، ستنتج المفاتيح المكررة في دالة حرفية ملف خطأ في بناء الجملة. لا يمكن أن تحتوي الوظيفة على معلمتين بنفس الاسم. لا يمكن أن تحتوي الوظيفة على متغير بنفس اسم أحدها المعلمات. لا يمكن للدالة حذف المتغيرات الخاصة بها. محاولة حذف خاصية غير قابلة للتكوين يطرح الآن استثناءً. بدائي القيم غير مغلفة ضمنيًا. الكلمات المحجوزة لإصدارات JavaScript المستقبلية يضيف ECMAScript 5 قائمة بالكلمات المحجوزة. إذا كنت تستخدمها كمتغيرات أو وسيطات ، فإن الوضع المتشدد سيؤدي إلى خطأ. الكلمات المحجوزة هي: أدوات ، واجهة ، اسمحوا ، حزمة ، خاصة ، محمية ، عامة ، ثابتة ، وعائد قراءة متعمقة الوضع الصارم - JavaScript | MDN دعم المتصفح للوضع الصارم الانتقال إلى الوضع المتشدد | أوصي بشدة كل مطور بالبدء في استخدام الوضع المتشدد الآن. هناك عدد كافٍ من المتصفحات التي تدعم ذلك الوضع الصارم سيساعد بشكل مشروع في إنقاذنا من الأخطاء التي لم نكن نعرف أنها موجودة في شفرتك. على ما يبدو ، في المرحلة الأولية ستكون هناك أخطاء لم نواجهها من قبل. للحصول على الفائدة الكاملة ، نحتاج إلى إجراء اختبار مناسب بعد التبديل إلى الوضع المتشدد للتأكد من أننا اكتشفنا كل شيء. من المؤكد أننا لا نكتفي باستخدام صارم في التعليمات البرمجية الخاصة بنا ونفترض عدم وجود أخطاء. لذا ، فقد حان الوقت للبدء في استخدام ميزة اللغة المفيدة للغاية هذه لكتابة كود أفضل. فمثلا، شخص فار = { الاسم: "xyz" ، الموضع: "abc" ، الاسم الكامل: الوظيفة () {"استخدام صارمة" ؛ إرجاع this.name ؛ } } ؛ JSLint هو مصحح أخطاء كتبه دوجلاس كروكفورد. ما عليك سوى لصق النص البرمجي ، وسيمسح سريعًا بحثًا عن أي مشاكل وأخطاء ملحوظة في شفرتك. | أود أن أقدم إجابة أكثر رسوخًا إلى حد ما تكمل الإجابات الأخرى. كنت أتمنى تعديل الإجابة الأكثر شيوعًا ، لكنني فشلت. حاولت أن أجعله شاملاً وكاملاً قدر الإمكان. يمكنك الرجوع إلى وثائق MDN لمزيد من المعلومات. "استخدام صارم" أحد التوجيهات المقدمة في ECMAScript 5. التوجيهات تشبه البيانات ، لكنها مختلفة. لا يحتوي userict على كلمات أساسية: التوجيه عبارة عن عبارة تعبير بسيطة ، والتي تتكون من سلسلة حرفية خاصة (بعلامات اقتباس فردية أو مزدوجة) محركات جافا سكريبت ، التي لا تنفذ ECMAScript 5 ، ترى فقط عبارة تعبير بدون آثار جانبية. من المتوقع أن تقدم الإصدارات المستقبلية من معايير ECMAScript الاستخدام ككلمة رئيسية حقيقية ؛ وبالتالي تصبح الاقتباسات قديمة. يمكن استخدام userict فقط في بداية النص أو الوظيفة ، أي أنه يجب أن يسبق كل بيان (حقيقي) آخر. ليس من الضروري أن تكون أول تعليمات في نص برمجي للوظيفة: يمكن أن تسبقها تعبيرات جمل أخرى تتكون من سلسلة حرفية (و JavaScriptيمكن أن تتعامل معها التطبيقات على أنها توجيهات محددة للتنفيذ). عبارات String literals ، التي تتبع أول جملة حقيقية (في نص أو وظيفة) هي عبارات تعبيرية بسيطة. يجب ألا يفسرها المترجمون الفوريون على أنها توجيهات وليس لها أي تأثير. يشير توجيه الاستخدام الصارم إلى أن الكود التالي (في برنامج نصي أو وظيفة) هو رمز صارم. تعتبر الكود الموجود في أعلى مستوى من البرنامج النصي (رمز غير موجود في وظيفة) رمزًا صارمًا عندما يحتوي البرنامج النصي على توجيه استخدام صارم. يعتبر محتوى الوظيفة رمزًا صارمًا عندما يتم تعريف الوظيفة نفسها في رمز صارم أو عندما تحتوي الوظيفة على توجيه استخدام صارم. تعتبر التعليمات البرمجية التي يتم تمريرها إلى طريقة EVAL () رمزًا صارمًا عندما يتم استدعاء EVAL () من رمز صارم أو يحتوي على توجيه الاستخدام الصارم نفسه. الوضع الصارم لـ ECMAScript 5 عبارة عن مجموعة فرعية مقيدة من لغة JavaScript ، والتي تقضي على أوجه القصور ذات الصلة في اللغة وتتميز بفحص أكثر صرامة للأخطاء وأمانًا أعلى. يسرد ما يلي الاختلافات بين الوضع المتشدد والوضع العادي (والتي تعتبر الثلاثة الأولى منها مهمة بشكل خاص): لا يمكنك استخدام العبارة with في الوضع المتشدد. في الوضع المتشدد ، يجب التصريح عن جميع المتغيرات: إذا قمت بتعيين قيمة لمعرف لم يتم التصريح به كمتغير أو وظيفة أو معلمة دالة أو معلمة جملة أو خاصية كائن عام ، فستحصل على خطأ ReferenceError في الوضع العادي ، يتم الإعلان عن المعرف ضمنيًا كمتغير عالمي (كخاصية للكائن العام) في الوضع المتشدد ، تحتوي الكلمة الأساسية هذه على قيمة غير محددة في الوظائف التي تم استدعاؤها كوظائف (وليس كطرق). (في الوضع العادي ، يشير هذا دائمًا إلى الكائن العام). يمكن استخدام هذا الاختلاف لاختبار ما إذا كان أحد التطبيقات يدعم الوضع المتشدد: var hasStrictMode = (function () {"use strict" ؛ إرجاع هذا === undefined} ()) ؛ أيضًا عندما يتم استدعاء دالة باستخدام call () أو تطبيقها في وضع صارم ، فهذه هي بالضبط قيمة الوسيطة الأولى للاستدعاء () أو التطبيق (). (في الوضع العادي ، يتم استبدال القيم الفارغة وغير المعرفة بالكائن العام والقيم ، التي ليست كائنات ، يتم وضعها في كائنات.) في الوضع المتشدد ، ستحصل على خطأ في النوع ، عندما تحاول تعيين خصائص للقراءة فقط أو لتعريف خصائص جديدة لكائن غير قابل للتوسيع. (في الوضع العادي يفشل كلاهما ببساطة بدون رسالة خطأ.) في الوضع المتشدد ، عند تمرير التعليمات البرمجية إلى EVAL () ، لا يمكنك التصريح أو تحديد المتغيرات أو الوظائف في نطاق المتصل (كما يمكنك القيام بذلك في الوضع العادي). بدلاً من ذلك ، يتم إنشاء نطاق جديد لـ Eval () والمتغيرات والوظائف ضمن هذا النطاق. يتم إتلاف هذا النطاق بعد انتهاء EVAL () من التنفيذ. في الوضع المتشدد ، تحتوي الوسيطات-وجوه الدالة على نسخة ثابتة من القيم التي يتم تمريرها إلى هذه الوظيفة. في الوضع العادي ، يتسم الكائن arguments بسلوك "سحري" إلى حد ما: تشير عناصر المصفوفة ومعلمات الوظيفة المسماة إلى نفس القيمة. في الوضع المتشدد ، ستحصل على خطأ في بناء الجملة عندما يتبع عامل الحذف معرف غير مؤهل (متغير أو دالة أو معلمة دالة). في الوضع العادي ، لن يفعل تعبير الحذف أي شيء ويتم تقييمه على خطأ. في الوضع المقيد ، ستحصل على خطأ في النوع عندما تحاول حذف خاصية غير قابلة للتكوين. (في الوضع العادي ، تفشل المحاولة ببساطة ويتم تقييم تعبير الحذف على خطأ). في الوضع المتشدد ، يعتبر خطأ نحويًا عندما تحاول تعريف عدة خصائص بنفس الاسم لكائن حرفي. (في الوضع العادي لا يوجد خطأ.) في الوضع المتشدد ، يُعتبر خطأ نحويًا عندما يكون لإعلان الدالة معلمات متعددة بنفس الاسم. (في الوضع العادي لا يوجد خطأ.) في الوضع المتشدد ، لا يُسمح بالحرف الثماني (هذه هي القيم الحرفية التي تبدأ بـ 0 x. (في الوضع العادي ، تسمح بعض التطبيقات بالحرف الثماني.) في الوضع المتشدد ، يتم التعامل مع المعرفات Eval و الوسيطات مثل الكلمات الرئيسية. لا يمكنك تغيير قيمتها ، ولا يمكنك تعيين قيمة لها ، ولا يمكنك استخدامها كأسماء للمتغيرات أو الوظائف أو معلمات الوظيفة أو معرفات كتلة catch. في الوضع المقيد توجد قيود أكثر على إمكانيات فحص مكدس الاستدعاءات. يتسبب arguments.caller و arguments.callee في حدوث خطأ TypeError في دالة في الوضع المتشدد. علاوة على ذلك ، تتسبب بعض خصائص المتصل والوسيطات للوظائف في الوضع المتشدد في حدوث خطأ في النوع عند محاولة قراءتها. | سنتى: أحد أهداف الوضع المتشدد هو السماح بتصحيح الأخطاء بشكل أسرع. يساعد المطورين من خلال طرح استثناء عند حدوث أشياء خاطئة معينة يمكن أن تسبب سلوكًا صامتًا وغريبًا لصفحة الويب الخاصة بك. في اللحظة التي نستخدم فيها صارمًا ، ستطرح الشفرة أخطاء تساعد المطور على إصلاحها مسبقًا. بعض الأشياء المهمة التي تعلمتها بعد استخدام صارم: يمنع إعلان المتغير العالمي: فار شجرة 1 البيانات= {name: 'Banana Tree'، العمر: 100، leafCount: 100000}؛ شجرة الوظيفة (typeOfTree) { عمر فار فار ليفكونت. العمر = typeOfTree.age ؛ LeafCount = typeOfTree.leafCount ؛ nameoftree = typeOfTree.name ؛ } ؛ var tree1 = شجرة جديدة (tree1Data) ؛ console.log (نافذة) ؛ الآن ، ينشئ هذا الرمز nameoftree في النطاق العالمي والذي يمكن الوصول إليه باستخدام window.nameoftree. عندما ننفذ استخدام صارم ، فإن الكود سيحدث خطأ. خطأ في مرجع غير معلوم: لم يتم تعريف nameoftree عينة يزيل ببيان: مع عبارات لا يمكن تصغيرها باستخدام أدوات مثل uglify-js. كما تم إهمالها وإزالتها من إصدارات JavaScript المستقبلية. عينة يمنع التكرارات: عندما يكون لدينا خاصية مكررة ، فإنه يطرح استثناء خطأ Syntax غير معلوم: خاصية البيانات المكررة في الكائن الحرفي لا مسموح به في الوضع المتشدد "استخدام صارم" ؛ var tree1Data = { الاسم: "شجرة الموز" ، العمر: 100، عدد الأوراق: 100000 ، الاسم: "شجرة الموز" } ؛ هناك القليل ولكني بحاجة إلى اكتساب المزيد من المعرفة حول ذلك. | إذا كنت تستخدم متصفحًا تم إصداره في العام الماضي أو نحو ذلك ، فمن المرجح أنه يدعم وضع JavaScript Strict. المتصفحات القديمة فقط قبل أن يصبح ECMAScript 5 هو المعيار الحالي لا تدعمه. تتأكد علامات الاقتباس حول الأمر من أن الشفرة ستظل تعمل في المتصفحات القديمة أيضًا (على الرغم من أن الأشياء التي تولد خطأ في بناء الجملة في الوضع المتشدد ستؤدي عمومًا إلى تعطل البرنامج النصي بطريقة يصعب اكتشافها في تلك المتصفحات القديمة) | عند إضافة "use strict" ؛ فإن الحالات التالية ستؤدي إلى خطأ في بناء الجملة قبل تنفيذ البرنامج النصي: تمهيد الطريق لإصدارات ECMAScript المستقبلية ، باستخدام واحدة من الكلمات الرئيسية المحجوزة حديثًا (في السابق لـ ECMAScript 6): الأدوات والواجهة والسماح والحزم والخاصة والمحمية والعامة والثابتة والعائد. إعلان الوظيفة في الكتل إذا (أ <ب) {الوظيفة و () {}} بناء الجملة الثماني فار ن = 023 ؛ هذه النقطة إلى الكائن العالمي. الوظيفة و () { "استخدام صارم" ؛ this.a = 1 ؛ } ؛ F()؛ التصريح مرتين عن نفس الاسم لاسم خاصية في كائن حرفي {أ: 1 ، ب: 3 ، أ: 7} لم يعد هذا هو الحال في ECMAScript 6 (الخطأ 1041128). التصريح عن وسيطتين للدالة بنفس الاسم و (أ ، ب ، ب) {} تحديد قيمة لمتغير غير معروف الوظيفة f (x) { "استخدام صارم" ؛ فار أ = 12 ؛ ب = أ + س * 35 ؛ // خطأ! } F()؛ باستخدام حذف على اسم متغير ، احذف myVariable ؛ استخدام الوسيطات EV أو الوسيطات كمتغير أو اسم وسيطة دالة "استخدام صارم" ؛ الحجج ++ ؛ var obj = {set p (وسيطات) {}} ؛ جرب {} catch (وسيطات) {} وسيطات الدالة () {} المصادر: الانتقال إلى الوضع المتشدد في MDN الوضع الصارم على MDN الوضع الصارم لجافا سكريبت ولماذا يجب استخدامه في مدونة Colin J. Ihrig (النسخة المؤرشفة) | يُجري الوضع Strict عدة تغييرات على دلالات JavaScript العادية: يزيل بعض أخطاء JavaScript الصامتة عن طريق تغييرها لرمي الأخطاء. يصلح الأخطاء التي تجعل من الصعب على JavaScript محركات لأداء التحسينات. يحظر بعض بناء الجملة من المحتمل أن يتم تعريفها في المستقبل إصدارات ECMAScript. لمزيد من المعلومات ، قم بزيارة Strict Mode- Javascript | "استخدام صارم" ؛ هو تأمين لن يستخدمه المبرمج الخصائص السائبة أو السيئة لجافا سكريبت. إنه دليل ، تمامًا مثل المسطرة ستساعدك على عمل خطوط مستقيمة. سيساعدك "Use Strict" على عمل "ترميز مباشر". أولئك الذين يفضلون عدم استخدام المساطر لعمل خطوطهم بشكل مستقيم ينتهي بهم الأمر عادةً في تلك الصفحات يطلبون من الآخرين تصحيح أخطاء الكود الخاص بهم. صدقني. النفقات العامة لا تذكر مقارنة بالتعليمات البرمجية سيئة التصميم. دوج كروكفورد ، الذي كان أحد كبار مطوري جافا سكريبت لعدة سنوات ، لديه منشور مثير للاهتمام هنا. أنا شخصياً أحب العودة إلى موقعه طوال الوقت للتأكد من أنني لا أنسى ممارساتي الجيدة. يجب أن تستدعي ممارسة JavaScript الحديثة "Use Strict" ؛ براغما. السبب الوحيد الذي جعل ECMA Group تجعل الوضع "Strict" اختياريًا هو السماح للمبرمجين الأقل خبرة بالوصول إلى JavaScript وإعطاء الوقت بعد ذلك للتكيف مع ممارسات التشفير الجديدة والأكثر أمانًا. | يعد تضمين استخدام صارم في بداية جميع ملفات JavaScript الحساسة من هذه النقطة طريقة صغيرة لتصبح مبرمج JavaScript أفضل وتجنب أن تصبح المتغيرات العشوائية عالمية وتتغير الأشياء بصمت. | نقلا عن w3schools: توجيه "الاستخدام الصارم" التوجيه "use strict" جديد في JavaScript 1.8.5 (ECMAScript الإصدار 5). إنه ليس بيانًا ، ولكنه تعبير حرفي ، تم تجاهله سابقًا إصدارات JavaScript. الغرض من "use strict" هو الإشارة إلى أن الكود يجب أن يكون كذلك تم تنفيذه في "الوضع الصارم". مع الوضع المتشدد ، لا يمكنك ، على سبيل المثال ، استخدام متغيرات غير معرّفة. لماذا الوضع الصارم؟ يسهّل الوضع الصارم كتابة JavaScript "آمن". تغييرات الوضع الصارم التي تم قبولها سابقًا "بناء جملة سيء" إلى أخطاء حقيقية. كمثال ، في JavaScript العادي ، يؤدي الخطأ في كتابة اسم المتغير إلى إنشاء متغير عالمي جديد. في الوضع المتشدد ، سيؤدي ذلك إلى حدوث خطأ ، مما يجعل من المستحيل إنشاء متغير عام بطريق الخطأ. في جافا سكريبت العادي ، أالمطور لن يتلقى أي ملاحظات خطأ تعيين قيم لخصائص غير قابلة للكتابة. في الوضع المتشدد ، أي تخصيص لخاصية غير قابلة للكتابة ، أ getter-only خاصية غير موجودة وغير موجودة متغير ، أو كائن غير موجود ، سيؤدي إلى حدوث خطأ. يرجى الرجوع إلى http://www.w3schools.com/js/js_strict.asp لمعرفة المزيد | يؤدي استخدام "استخدام صارم" إلى تشغيل كود JavaScript في الوضع المتشدد ، وهو ما يعني أساسًا أنه يجب تحديد كل شيء قبل الاستخدام. السبب الرئيسي لاستخدام الوضع المتشدد هو تجنب الاستخدامات العالمية العرضية للطرق غير المحددة. أيضًا في الوضع الصارم ، تعمل الأشياء بشكل أسرع ، وتؤدي بعض التحذيرات أو التحذيرات الصامتة إلى حدوث أخطاء فادحة ، فمن الأفضل دائمًا استخدامها لإنشاء رمز أكثر إتقانًا. هناك حاجة على نطاق واسع لاستخدام "use strict" في ECMA5 ، فهي في ECMA6 جزءًا من JavaScript افتراضيًا ، لذا لا يلزم إضافتها إذا كنت تستخدم ES6. انظر إلى هذه العبارات والأمثلة من MDN: التوجيه "استخدام صارم" يعد التوجيه "استخدام صارم" جديدًا في JavaScript 1.8.5 (ECMAScript الإصدار 5). إنه ليس بيانًا ، بل أ تعبير حرفي تتجاهله الإصدارات السابقة من JavaScript. ال الغرض من "استخدام صارم" هو الإشارة إلى أن الشفرة يجب أن تكون كذلك تم تنفيذه في "الوضع الصارم". مع الوضع الصارم ، لا يمكنك ، على سبيل المثال ، استخدام متغيرات غير معلنة. أمثلة على استخدام "use strict": الوضع المتشدد للوظائف: وبالمثل ، لاستدعاء الوضع المتشدد لـ وظيفة ، ضع العبارة الدقيقة "استخدام صارم" ؛ (أو "استخدام صارمة" ؛) في جسم الوظيفة قبل أي عبارات أخرى. 1) الوضع الصارم في الوظائف دالة صارمة () { // بناء جملة الوضع الصارم على مستوى الوظيفة "استخدام صارم" ؛ وظيفة متداخلة () {return 'And so am I!'؛ } إرجاع "مرحبًا! أنا وظيفة ذات وضع صارم!" + متداخل () ؛ } function notStrict () {return "أنا لست صارمًا."؛ } console.log (strict ()، notStrict ()) ؛ 2) الوضع الصارم للنص الكامل "استخدام صارم" ؛ var v = "مرحبًا! أنا برنامج نصي شديد الوضع!" ؛ console.log (ت) ؛ 3) التنازل عن عالمية غير قابلة للكتابة "استخدام صارم" ؛ // التنازل إلى عالم غير قابل للكتابة var undefined = 5 ؛ // يطرح TypeError فار إنفينيتي = 5 ؛ // يطرح TypeError // التنازل عن خاصية غير قابلة للكتابة var obj1 = {} ، Object.defineProperty (obj1، 'x'، {القيمة: 42، writable: false}) ؛ obj1.x = 9 ؛ // يطرح TypeError // التعيين إلى خاصية getter-only var obj2 = {get x () {return 17 ؛ }}؛ obj2.x = 5 ؛ // يطرح TypeError // التعيين إلى خاصية جديدة على كائن غير قابل للتوسيع. فار ثابت = {} ؛ Object.preventExtensions (ثابت) ؛ Fixed.newProp = 'ohai' ؛ // يطرح TypeError يمكنك قراءة المزيد عن MDN. | هناك حديث جيد من قبل بعض الأشخاص الذين كانوا أعضاء في لجنة ECMAScript: التغييرات التي تم إجراؤها على JavaScript ، الجزء 1: ECMAScript 5 "حول كيف يسمح الاستخدام المتزايد لمفتاح التبديل" use strict "لمنفذي JavaScript بتنظيف الكثير من الميزات الخطيرة لـ JavaScript بدون فجأة كسر كل موقع في العالم. بالطبع يتحدث أيضًا عن ماهية الكثير من هذه الميزات الخاطئة وكيف يعمل ECMAScript 5 على إصلاحها. | أمثلة صغيرة للمقارنة: الوضع غير المقيد: لـ (i of [1،2،3]) console.log (i) // انتاج: // 1 // 2 // 3 الوضع الصارم: "استخدام صارم" ؛ لـ (i من [1،2،3]) console.log (i) // انتاج: // Uncaught ReferenceError: لم يتم تعريف i الوضع غير المقيد: String.prototype.test = وظيفة () { console.log (typeof this === 'سلسلة') ؛ } ؛ 'اختبار()؛ // انتاج // خاطئة String.prototype.test = وظيفة () { "استخدام صارم" ؛ console.log (typeof this === 'سلسلة') ، } ؛ 'اختبار()؛ // انتاج // صحيح | لاحظ أن use strict تم تقديمه في EcmaScript 5 وتم الاحتفاظ به منذ ذلك الحين. فيما يلي الشروط لتشغيل الوضع المتشدد في ES6 و ES7: الكود العام هو كود وضع صارم إذا بدأ بمبدأ توجيهي يحتوي على استخدام توجيه صارم (انظر 14.1.1). رمز الوحدة هو دائمًا رمز الوضع الصارم. جميع أجزاء إعلان Class أو ClassExpression هي رمز وضع صارم. رمز التقييم هو رمز وضع صارم إذا بدأ بمبدأ توجيهي يحتوي على استخدام توجيه صارم أو إذا كان استدعاء التقييم عبارة عن تقييم مباشر (انظر 12.3.4.1) مضمّن في كود الوضع المقيد. رمز الوظيفة هو رمز وضع صارم إذا كان تعريف الوظيفة المرتبط ، أو التعبير عن الوظيفة ، أو المُنشئ ، أو المُنشئ ، أو التعبير ، أو تعريف الطريقة ، أو دالة السهم مضمنًا في رمز الوضع الصارم أو إذا كان الرمز الذي ينتج عنه قيمة الفتحة الداخلية [[ECMAScriptCode]] للوظيفة تبدأ بمبدأ توجيهي الذي يحتوي على استخدام التوجيه الصارم. رمز الوظيفة الذي يتم توفيره كوسائط إلى مُنشئ الدالة والمُنشئ المدمجين هو رمز وضع صارم إذا كانت الوسيطة الأخيرة عبارة عن سلسلة عند معالجتها هي FunctionBody تبدأ بمبدأ توجيهي يحتوي على استخدام التوجيه الصارم. | الأسباب الرئيسية التي تدفع المطورين لاستخدام "use strict" هي: يمنع الإعلان غير المقصود عن المتغيرات العامة. باستخدام "use strict ()" ، سيضمن التصريح عن المتغيرات مع var قبل الاستخدام. على سبيل المثال: وظيفة useStrictDemo () { "استخدام صارم" ؛ //يعمل بشكل جيد فارأ = "لا مشكلة" ؛ // لا يعمل بشكل جيد ويرمي الخطأ ك = "مشكلة" // حتى هذا سيرمي الخطأ someObject = {'مشكلة': 'الكثير من المشاكل'} ؛ } ملاحظة: لا يتم التعرف على التوجيه "use strict" إلا في بداية النص أو الوظيفة. لا يمكن استخدام سلسلة "الوسيطات" كمتغير: "استخدام صارم" ؛ الوسيطات var = 3.14 ؛ // سيؤدي هذا إلى حدوث خطأ سيتم تقييد استخدام الكلمات الرئيسية كمتغيرات. ستؤدي محاولة استخدامها إلى ظهور أخطاء. باختصار ، ستجعل الكود الخاص بك أقل عرضة للخطأ وسيجعلك تكتب رمزًا جيدًا. لقراءة المزيد عنها يمكنك الرجوع هنا. | تم تقديم وضع JavaScript "صارم" في ECMAScript 5. (وظيفة() { "استخدام صارم" ؛ كودك ... }) () ؛ كتابة "استخدام صارم" ؛ في الجزء العلوي من ملف JS الخاص بك ، يتم تشغيل صارم التحقق من النحو. يقوم بالمهام التالية لنا: يظهر خطأ إذا حاولت التخصيص لمتغير غير معروف يمنعك من الكتابة فوق مكتبات نظام JS الرئيسية يحظر بعض ميزات اللغة غير الآمنة أو المعرضة للخطأ استخدام صارم يعمل أيضًا داخل الوظائف الفردية. من الأفضل دائمًا تضمين استخدام صارم في التعليمات البرمجية الخاصة بك. مشكلة توافق المستعرض: من المفترض أن تكون توجيهات "الاستخدام" متوافقة مع الإصدارات السابقة. المتصفحات التي لا تدعمها سترى فقط سلسلة حرفية لم تتم الإشارة إليها بعد ذلك. لذلك ، سوف يمرون فوقه ويمضون قدمًا. | يعد استخدام صارم طريقة لجعل التعليمات البرمجية أكثر أمانًا ، لأنه لا يمكنك استخدام ميزات خطيرة لا يمكن أن تعمل بالشكل الذي تتوقعه. وكما كتب من قبل ، فإنه يجعل الكود أكثر صرامة. | "استخدام صارم" ؛ هو جهد ECMA لجعل JavaScript أكثر قوة قليلاً. إنها تجلب JS محاولة لجعلها على الأقل "صارمة" قليلاً (تطبق اللغات الأخرى قواعد صارمة منذ التسعينيات). إنه في الواقع "يجبر" مطوري JavaScript على اتباع نوع من أفضل ممارسات الترميز. لا يزال ، جافا سكريبت هش للغاية. لا يوجد شيء مثل المتغيرات المكتوبة والطرق المكتوبة وما إلى ذلك. أوصي بشدة مطوري JavaScript بتعلم لغة أكثر قوة مثل Java أو ActionScript3 ، وتنفيذ نفس أفضل الممارسات في كود JavaScript الخاص بك ، وسوف يعمل بشكل أفضل ويسهل تصحيحه. | عادةً ، لا تتبع JavaScript قواعد صارمة ، وبالتالي تزيد فرص حدوث أخطاء. بعد استخدام "use strict" ، يجب أن تتبع شفرة JavaScript مجموعة صارمة من القواعد كما هو الحال في لغات البرمجة الأخرى مثل استخدام عوامل الإنهاء والإعلان قبل التهيئة ، إلخ إذا تم استخدام "use strict" ، فيجب كتابة الكود باتباع مجموعة صارمة من القواعد ، وبالتالي تقليل فرص الأخطاء والغموض. | يُستخدم استخدام Strict لإظهار الأخطاء الشائعة والمتكررة بحيث يتم التعامل معها بشكل مختلف ، وتغيير طريقة تشغيل نص جافا ، وهذه التغييرات هي: يمنع الكرات الأرضية العرضية لا يوجد تكرارات يزيل مع يزيل هذا الإكراه تقييم أكثر أمانًا () أخطاء للأشياء الثابتة يمكنك أيضًا قراءة هذه المقالة للحصول على التفاصيل | "استخدام صارم" ؛ يحدد أن تعليمات JavaScript البرمجية يجب أن يتم تنفيذها "الوضع الصارم". كان التوجيه "use strict" جديدًا في ECMAScript الإصدار 5. إنه ليس بيانًا ، ولكنه تعبير حرفي ، تم تجاهله سابقًا إصدارات JavaScript. الغرض من "use strict" هو الإشارة إلى أن الكود يجب أن يكون كذلك تم تنفيذه في "الوضع الصارم". مع الوضع المتشدد ، لا يمكنك ، على سبيل المثال ، استخدام متغيرات غير معرّفة. تدعم كافة المتصفحات الحديثة "استخدام صارم" باستثناء Internet Explorer 9 والإصدارات الأقل. عيب إذا استخدم أحد المطورين مكتبة كانت في الوضع المتشدد ، ولكن المطور معتاد على العمل في الوضع العادي ، فقد يستدعي بعض الإجراءات في المكتبة التي لن تعمل بالشكل المتوقع. والأسوأ من ذلك ، نظرًا لأن المطور في الوضع العادي ، فلن يتمتع بمزايا الأخطاء الإضافية التي يتم إلقاؤها ، لذلك قد يفشل الخطأ بصمت. أيضًا ، كما هو مذكور أعلاه ، يمنعك الوضع الصارم من القيام بأشياء معينة. يعتقد الناس عمومًا أنه لا يجب عليك استخدام هذه الأشياء في المقام الأول ، لكن بعض المطورين لا يحبون القيد ويريدون استخدام جميع ميزات اللغة. للحصول على مثال أساسي وللمرجع ، انتقل من خلال: https://www.tutorialsteacher.com/javascript/javascript-strict | يمكن أن يمنع الوضع المتشدد تسرب الذاكرة. يرجى التحقق من الوظيفة أدناه المكتوبة في الوضع غير الصارم: وظيفة getname () { الاسم = "Stack Overflow" ؛ // لا تستخدم var الكلمة اسم العودة } getname () ؛ console.log (الاسم) ؛ // Stack Overflow في هذه الوظيفة ، نستخدم متغيرًا يسمى name داخل الدالة. داخليًا ، سيتحقق المترجم أولاً مما إذا كان هناك أي متغير تم الإعلان عنه بهذا الاسم المعين في نطاق الوظيفة المحدد. نظرًا لأن المترجم يفهم أنه لا يوجد مثل هذا المتغير ، فإنه سيتحقق من النطاق الخارجي. في حالتنا ، هذا هو النطاق العالمي. مرة أخرى ، أدرك المترجم أنه لا يوجد أيضًا متغير معلن في الفضاء العالمي بهذا الاسم ، لذلك فإنه يخلق مثل هذا المتغير لنا في الفضاء العالمي. من الناحية المفاهيمية ، سيتم إنشاء هذا المتغير في النطاق العالمي وسيكون متاحًا في التطبيق بأكمله. آخرالسيناريو هو أنه ، على سبيل المثال ، يتم الإعلان عن المتغير في دالة تابعة. في هذه الحالة ، يتحقق المترجم من صلاحية هذا المتغير في النطاق الخارجي ، أي الوظيفة الأصلية. عندها فقط سيتم التحقق من المساحة العامة وإنشاء متغير لنا هناك. وهذا يعني أنه يلزم إجراء فحوصات إضافية. سيؤثر هذا على أداء التطبيق. لنكتب الآن نفس الوظيفة في الوضع المتشدد. "استخدام صارم" وظيفة getname () { الاسم = "Stack Overflow" ؛ // لا تستخدم var الكلمة اسم العودة } getname () ؛ console.log (الاسم) ؛ سوف نحصل على الخطأ التالي. خطأ مرجع غير معلوم: لم يتم تعريف الاسم في getname (<مجهول>: 3: 15) في <مجهول>: 6: 5 هنا ، يقوم المترجم بإلقاء الخطأ المرجعي. في الوضع المتشدد ، لا يسمح لنا المترجم باستخدام المتغير دون الإعلان عنه. لذلك يمكن منع تسرب الذاكرة. بالإضافة إلى ذلك ، يمكننا كتابة المزيد من التعليمات البرمجية المحسّنة. | يزيل الوضع المتشدد الأخطاء التي يمكن تجاهلها في الوضع غير المقيد ، مما يجعل جافا سكريبت "أكثر أمانًا". هل تعتبر من بين أفضل الممارسات؟ نعم ، يعتبر جزءًا من أفضل الممارسات أثناء العمل باستخدام جافا سكريبت لتضمين الوضع الصارم. يتم ذلك عن طريق إضافة سطر التعليمات البرمجية أدناه في ملف JS الخاص بك. "استخدام صارم" ؛ في التعليمات البرمجية الخاصة بك. ماذا يعني ذلك لوكلاء المستخدم؟ الإشارة إلى أن الكود يجب أن يتم تفسيره في الوضع المتشدد يحدد لوكلاء المستخدم مثل المتصفحات أنه يجب عليهم التعامل مع الكود حرفيًا كما هو مكتوب ، وإلقاء خطأ إذا لم يكن الرمز منطقيًا. على سبيل المثال: ضع في اعتبارك أن لديك الكود التالي في ملف .js الخاص بك: السيناريو 1: [NO STRICT MODE] var city = "Chicago" console.log (المدينة) // يطبع اسم المدينة ، أي شيكاغو السيناريو 2: [NO STRICT MODE] المدينة = "شيكاغو" console.log (المدينة) // يطبع اسم المدينة ، أي شيكاغو فلماذا يتم طباعة اسم المتغير في كلتا الحالتين؟ بدون تشغيل الوضع المتشدد ، غالبًا ما يمر وكلاء المستخدم بسلسلة من التعديلات على التعليمات البرمجية الإشكالية في محاولة لجعلها منطقية. ظاهريًا ، قد يبدو هذا شيئًا رائعًا ، وبالفعل ، فإن العمل خارج الوضع الصارم يجعل من الممكن للأشخاص أن يبللوا أقدامهم باستخدام كود JavaScript دون الحاجة إلى توضيح جميع التفاصيل تمامًا. ومع ذلك ، بصفتي مطورًا ، لا أرغب في ترك خطأ في الكود الخاص بي ، لأنني أعلم أنه يمكن أن يعود ويعضني لاحقًا ، وأريد أيضًا كتابة رمز جيد. وهذا هو المكان الذي يساعد فيه الوضع المتشدد. السيناريو 3: [الوضع الصارم] "استخدام صارم" ؛ المدينة = "شيكاغو" console.log (city) // خطأ مرجعي: التعيين هو مدينة متغيرة غير معلنة. نصيحة إضافية: للحفاظ على جودة الكود باستخدام الوضع المتشدد ، لن تحتاج إلى كتابة هذا مرارًا وتكرارًا خاصةً إذا كان لديك ملف .js متعدد. يمكنك فرض هذه القاعدة عالميًا في قواعد eslint على النحو التالي: اسم الملف: .eslintrc.js module.exports = { env: { es6: صحيح } ، قواعد : { صارمة: ["خطأ" ، "عمومي"] ، } ، } ؛ حسنًا ، ما الذي يتم منعه في الوضع المتشدد؟ سيؤدي استخدام متغير بدون التصريح إلى حدوث خطأ في الوضع المتشدد. هذا لمنع إنشاء متغيرات عامة عن غير قصد في جميع أنحاء التطبيق الخاص بك. المثال مع طباعة شيكاغو يغطي هذا على وجه الخصوص. يعتبر حذف متغير أو دالة أو وسيطة أمرًا محظورًا في الوضع المتشدد. "استخدام صارم" ؛ الوظيفة x (p1، p2) {} ؛ حذف x ؛ // سيؤدي هذا إلى حدوث خطأ لا يُسمح بتكرار اسم المعلمة في الوضع المتشدد. "استخدام صارم" ؛ الوظيفة x (p1، p1) {} ؛ // سيؤدي هذا إلى حدوث خطأ غير مسموح بالكلمات المحجوزة في لغة Javascript في الوضع المتشدد. الكلمات هي واجهة تنفذ الحزم الخاصة المحمية العامة. ثابت ، والعائد للحصول على قائمة أكثر شمولاً تحقق من وثائق MDN هنا: | سؤال نشط للغاية. اكسب 10 سمعة للإجابة على هذا السؤال. تساعد متطلبات السمعة في حماية هذا السؤال من البريد العشوائي ونشاط عدم الإجابة. ليس الجواب الذي تبحث عنه؟ تصفح الأسئلة الأخرى الموسومة ببناء جافا سكريبت jslint use-strict أو اطرح سؤالك الخاص.